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ABSTRACT: 

A network access authentication system including a directory service containing a remote access 
password and a standard access password for each user of the network, using an authentication 
protocol that provides information on whether a user is accessing the network locally or remotely, 
and including a front-end between the directory service and the authentication protocol. The 
front-end executes the steps of: receiving a user identifier and a user password entered by a 
user through said authentication protocol; retrieving from the directory service the remote 
access password andthe standard access password corresponding to the user identifier; if the 
authentication protocol indicates a remote access, comparing the user password to the remote 
access password, else comparing the user password to the standard access password; and 
granting access to the network if the comparing step is successful. 
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(57) A network access authentication system 
including a directory service containing a remote 
access password and a standard access password for 
each user of the network, using an authentication proto- 
col that provides information on whether a user is 
accessing the network locally or remotely, and including 
a front-end between the directory service and the 
authentication protocol. The front-end executes the 
steps of: 

receiving a user identifier and a user password 
entered by a user through said authentication pro- 



tocol; 

retrieving from the directory service the remote 
access password and the standard access pass- 
word corresponding to the user identifier; 
if the authentication protocol indicates a remote 
access, comparing the user password to the 
remote access password, else comparing the user 
password to the standard access password; and 
granting access to the network rf the comparing 
step is successful. 
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Description 

[0001 ] The present invention relates to an authentica- 
tion system for users which may access a network 
locally or remotely s 
[0002] Figure 1 illustrates an exemplary network. The 
network includes a network server 10 having a mass 
storage device 10-1 and several local clients 12 con- 
nected to each other and to server 1 0 through a network 
link 14, such as an Ethernet link. 10 
[0003] The network may also include a Network 
Access Server (NAS) 16 connected to link 14, that 
allows remote clients 18 to connect to the network, for 
example through a modem and a telephone line. In this 
manner, users may access their business network from is 
home. 

[0004] In order to have access to a network, a user 
must first be authenticated, i.e. he must provide a user 
identifier and a password which must match authentica- 
tion data previously created for the user by the network 20 
administrator. Such data is usually stored in a user data 
file on the network server 10. 

[0005] Usual network transport protocols, such as 
TCP/IP, are not specifically intended for authentication. 
Therefore, specific protocols are used on top of the 25 
transport protocols, some of which are dedicated to 
authentication and some others, although not dedi- 
cated, may be used for authentication. The non-dedi- 
cated protocols (such as NiS), which may convey 
passwords as clear text, are often used on small local 30 
area networks (LAN) where strong security is not an 
issue. If more security is needed, dedicated authentica- 
tion protocols, such as RADIUS (Remote Authentication 
Dial In User Service) or TACACS, are used. 
[0006] With the RADIUS protocol, a NAS operates as 35 
a client of RADIUS. The client is responsible for passing 
user information to designated RADIUS servers, and 
then acting on the response which is returned. RADIUS 
servers are responsible for receiving user connection 
requests, authenticating the user, and then returning all 40 
configuration information necessary for the client to 
deliver service to the user. 

[0007] A RADIUS server can act as a proxy client to 
other RADIUS servers or other kinds of authentication 
servers. 45 
[0008] Transactions between the client and RADIUS 
server are authenticated through the use of a shared 
secret, which is never sent over the network. In addition, 
any user passwords are sent encrypted between the cli- 
ent and RADIUS server, to eliminate the possibility that so 
someone snooping on an unsecure network could 
determine a user's password. 

[0009] The RADIUS server can support a variety of 
methods to authenticate a user. When it is provided with 
the user name and original password given by the user. 55 
it can support PPP PAP or CHAP, UNIX login, and other 
authentication mechanisms. 

[0010] All transactions are comprised of variable 
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length Attribute-Length-Value 3-tuples. New attribute 
values can be added without disturbing existing imple- 
mentations of the protocol. 

[0011] TACACS is an industry standard specification 
that forwards user name and password information to a 
centralized server. The centralized server can either be 
a TACACS database or a database like the UNIX pass- 
word fBe with TACACS protocol support. For example, 
the UNIX server with TACACS passes requests to the 
UNIX database and sends accept or reject messages 
back to the access server. XTACACS is an extension of 
the TACACS protocol that authorizes connections with 
SLIP, enable, PPP (IP or IPX), ARA, EXEC, and Telnet 
[0012] The protocols mentioned in the present appli- 
cation and others are well documented in RFC 
(Request For Comments) papers available on Internet 
at: 

www.nexor.cxxnyjDublicyrf(^rKJex/rfc.html. 
In particular, the RADIUS and TACACS protocols are 
documented in RFC papers 1 492, 2058 and 21 38 which 
are incorporated herein by reference. 
[0013] Ail these protocols require different user data 
files. As a consequence, in a large network where many 
protocols coexist, a user may have data stored in sev- 
eral different files scattered on the network. This makes 
the network administration complex, since the adminis- 
trator will have to update several files each time he cre- 
ates a user or modifies the data of an existing user. 
There may even be several administrators in charge of 
different services. Unless these administrators attempt 
to synchronize with each other, the user ends up with 
several user identifiers and passwords which will be dif- 
ficult to remember. 

[001 4] For improving the security of a network provid- 
ing remote access, it is usually recommended to use at 
least two different passwords, one for remote access 
and the other for local access. 
[0015] An object of the invention is to provide an 
authentication procedure which allows a centralized 
administration of user data without creating security 
breaches in networks providing remote access. 
[0016] This object and others are achieved by an 
authentication system including a directory service con- 
taining a remote access password and a standard 
access password for each user of the network, using an 
authentication protocol that provides information on 
whether a user is accessing the network locally or 
remotely, and including a front-end between the direc- 
tory service and the authentication protocol. The front- 
end receives a user identifier and a user password 
entered by a user through the authentication protocol, 
and retrieves from the directory service the remote 
access password and the standard access password 
corresponding to the user identifier. If the authentication 
protocol indicates a remote access, the front-end com- 
pares the user password to the remote access pass- 
word, else it compares the user password to the 
standard access password. Access to the network is 
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granted if the comparison is successful. 
[001 7] The directory service may additionally contain 
a remote access password enable flag for each user of 
the network. In this case, if the authentication protocol 
indicates a remote access corresponding to the remote 
access enable flag and the remote access enable flag 
has an active state, the front-end compares the user 
password to the remote access password, else it com- 
pares the user password to the standard access pass- 
word. Access to the network is granted if the 
comparison is successful. 

[0018] According to an embodiment of the invention, 
the front-end behaves as a client for a protocol used by 
the directory service and as a server for the authentica- 
tion protocol, and exchanges information between the 
authentication protocol and the directory service proto- 
col using a protocol attribute translation table. 
[0019] According to an embodiment of the invention, 
several authentication protocols are used on the net- 
work and one front-end is provided for each authentica- 
tion protocol. 

[0020] The foregoing and other objects, features, 
aspects and advantages of the invention will become 
apparent from the following detailed description of 
embodiments, given by way of illustration and not of lim- 
itation with reference to the accompanying drawings. 

Figure 1 schematically shows an exemplary net- 
work; 

Figure 2 illustrates an exemplary data flow of an 
authentication system according to the invention; 
and 

Figure 3 is a flow chart of operations achieved by a 
front-end application of figure 2 during an authenti- 
cation operation according to the invention. 

[0021] An aspect of the invention is to gather all the 
data concerning the network users, including their 
authentication data, in a data base of a directory serv- 
ice. A directory service is a combination of a data base, 
or directory, and a specific protocol allowing access to 
the directory through a network. A directory contains 
information of any type. 

[0022] A preferred embodiment of the invention uses 
the Lightweight Directory Access Protocol (LDAP). The 
LDAP protocol is designed to provide access to directo- 
ries supporting the X.500 models, while not incurring 
the resource requirements of the X.500 Directory 
Access Protocol (DAP). This protocol is specifically tar- 
geted at management applications and browser appli- 
cations that provide read/write interactive access to 
directories. When used with a directory supporting the 
X.500 protocols, it is intended to be a complement to the 
X.500 DAP The protocol is carried directly over TCP or 
other transport, bypassing much of the session/ftresen- 
tation overhead of X.500 DAP Most protocol data ele- 
ments can be encoded as ordinary strings (e.g., 
Distinguished Names). The protocol can be extended to 



support new operations, and controls may be used to 
extend existing operations. 

[0023] The LDAP protocol and related information are 
documented in RFCs 1 777, 1 778, 2251 , 2252 and 2256 

5 which are incorporated herein by reference and availa- 
ble on Internet at: 

www.nexor.comftuWic/rftfndex/rf^ 
[0024] As shown in figure 1 , a network according to 
the invention is connected to a server 20 hosting a 

10 directory service associated with a directory stored on a 
mass storage device 20-1 . This directory will contain all 
the data, especially the authentication data, concerning 
the network users. Although figure 1 shows a server 20 
dedicated to the directory service, the directory service 

15 could also be hosted by the main network server 10. 
[0025] The directory is accessible through a network 
client using the appropriate protocol (an LDAP client 12 
in Figure 1). 

[0026] A goal of the invention is to make any authen- 

20 tication procedure on the network use the authentica- 
tion data stored in the directory. In this manner, since 
the same authentication data is accessible to all the 
authentication procedures, this authentication data in 
principle only needs to contain one user identifier and 

25 one password. In practice, the authentication data will 
contain two passwords for security reasons if the net- 
work offers remote access. This will considerably 
increase the comfort of the users and simplify the net- 
work administrator's tasks. 

30 [0027] Making any authentication procedure use the 
directory service is however not straightforward. 
Although directory service protocols, such as LDAP, 
provide authentication possibilities for restricting access 
to the directory, they are not compatible with the proto- 

35 cols used for user authentication on the network, such 
as RADIUS and TACACS. 

[0028] Another difficulty results from the coexistence 
of two passwords, recommended when the network 
offers remote access. The protocols used for authenti- 

40 cation only convey a single password, the one entered 
by the user, which may be the remote access password 
or the standard access password. Although the usual 
authentication protocols convey information on the 
access mode (remote or local), such information is not 

45 exploitable by the drectory service protocols for retriev- 
ing the right password among the two passwords stored 
in the directory for a user. 

[0029] Figure 2 illustrates how these difficulties are 
overcome according to the invention, ft shows an exem- 

so plary data flow of an authentication system according to 
the invention. A front-end application 22 is provided for 
each protocol which is used on the network for authen- 
tication. Figure 2 shows, as an example, a RADIUS 
front-end and a TACACS front-end. Each front-end is an 

55 interface between the central directory service 24 and a 
client using the corresponding authentication protocol. 
For this purpose, each front end behaves as a client of 
the directory service and therefore exchanges informa- 
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tion with the directory service using the directory serv- 
ice protocol, LDAP in the preferred embodment 
Moreover, the front-end behaves as the server for the 
clients using the corresponding authentication protocol. 
As shown, a NAS (network access server) 16 runs a 5 
RADIUS client which will exchange authentication infor- 
mation with the corresponding front-end 22 by using the 
RADIUS protocol. Remote clients connect to the NAS 
16 using, for example, the Point-to-Point Protocol 
(PPP). 10 
[0030] The front-ends 22 are, in a preferred embodi- 
ment, implemented within the computer 20 hosting the 
directory service. They can however be implemented in 
other computers connected to the network. 
[0031 ] The directory is maintained by an administrator is 
using a conventional LDAP client (shown in Figure 1). 
[0032] When a remote user wishes to access the net- 
work, he provides a user identifier XUserld and a pass- 
word XPassWd. This information is passed to the 
RADIUS client application which conventionally carries 20 
out a RADIUS authentication transaction with the avail- 
able RADIUS server, i.e. the RADIUS front-end accord- 
ing to the invention. 

[0033] According to the RADIUS protocol, like for 
other high-level protocols such as TACACS and LDAP, 25 
information is exchanged in the form of attributes. Each 
attribute has a unique attribute identifier and an attribute 
value. 

[0034] During the RADIUS authentication transaction, 
the client will in particular pass to the RADIUS server 30 
the attributes "User-Name" with the value XUserld (the 
user identifier entered by the remote user), the attribute 
"Password" with the value XPassWd (the password 
entered by the remote user), and the attribute "Framed- 
Protocol" with a value indicating if a remote access pro- 35 
tocol is used and if so r which one (in this case PPP). In 
practice, the password XPassWd will be encrypted on 
the PPP link and decrypted by the NAS 16. The 
RADIUS client will again encrypt the password conform- 
ing to the RADIUS specifications. 40 
[0035] The RADIUS server needs to compare the user 
identifier and the password with predefined values 
which, in a conventional system, are stored in a dedi- 
cated file. According to the invention, the front-end's 
RADIUS server, instead of retrieving this data in a file, 45 
will make the front-end's LDAP client fetch it from the 
directory service 24. For this purpose, the front-end 
converts the required RADIUS attributes to LDAP 
attributes using an attribute mapping table 22-1. In par- 
ticular, the RADIUS attribute "User-Name" is mapped to so 
the LDAP attribute "uid". The LDAP client then conven- 
tionally issues a request to the LDAP server for data 
associated to attribute "uid" having value XUserld (the 
user identifier). The LDAP server conventionally returns 
the requested attributes with their corresponding values 55 
stored in the directory. 

[0036] In figure 2, the requested attributes are. for 
example. "userPassword", which is a password to use 



for local or standard accesses, "PppPassWd" which is a 
password to use normally for remote accesses, and 
"PppProFile" which is a flag that indicates if the user 
should use his remote access password or not when 
using a remote access. Depending on the values of 
these attributes and those received from the RADIUS 
client, the front-end's RADIUS server will either deny or 
grant access to the network. 

[0037] Figure 3 shows an exemplary flow chart of the 
operations carried out by the RADIUS front-end of fig- 
ure 2 when a user wishes to access the network 
remotely. 

[0038] At 100, the front-end receives from the 
RADIUS client the attributes corresponding to the user 
identifier XUserld, the entered password XPassWd, and 
the type of the remote access protocol, PPP. The two 
first values are provided by the user, whereas the third 
value is provided by the RADIUS client which is aware 
of the type of remote access protocol used. 
[0039] At 102, the RADIUS attribute "User-Name" is 
mapped to the LDAP attribute "uid" with the user identi- 
fier value XUserld. An LDAP request is then issued to 
retrieve from the directory the attributes "userPass- 
word", "PppPassWd" and "PppProFile" from an entry 
corresponding to value XUserld for attribute "uid". 
[0040] At 104, if the LDAP server cannot satisfy the 
request because no entry corresponds to XUserld, the 
access to the network is denied at 1 06. Else, at 1 08, the 
value the "Framed-Protocol" attribute is checked. 
[0041] If at 108 the "Framed-Protocol" attribute indi- 
cates a PPP access, it is checked whether the "PppPro- 
ffle" flag is zero at 1 14. The "PppProfile" flag is optional 
and allows the administrator to force a user either to 
always use the same password, i.e. the standard 
access password, whether he is accessing the network 
remotely or not, or to force the user to use different 
passwords depending on the access mode. 
[0042] If the "PppProfile" attribute is not zero at 1 14, 
the password XPassWd entered by the user is com- 
pared to the value of attribute "PppPassWd" at 1 16. If 
the comparison fails, access is denied at 106. Other- 
wise, access is granted at 1 12. 
[0043] rf the "PppProfile" attribute is zero at 1 1 4, the 
password XPassWd entered by the user is compared at 
1 18 to the value of attribute "userPassword" returned by 
the LDAP server, rf the comparison fails, access is 
denied at 106. whereas, if it is successful, access is 
granted at 112. 

[0044] If, at 108. the "Framed-Protocol" attribute does 
not indicate a PPP access, the same steps as carried 
out for the PPP access mode from 1 14 are carried out 
at 120 for any other possible access mode identified by 
the "Framed-Protocol" attribute. For example, if another 
possible remote access mode is SLIP, an enable flag 
"SlipProfile" and a password attribute "SlipPassWd" 
may be set for the user in the directory. The values of 
these attributes are compared respectively to zero and 
to the password XPassWd at steps similar to steps 114 
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and 116. Access is then granted or denied at steps sim- 
ilar to 1 12 or 106 if the flag "SlipProfile" is non zero. 
[0045] If flag "SlipProfile" is zero or rf no remote 
access mode is identified, the password XPassWd is 
compared to the value of attribute "userPassword" at s 
118 before granting or denying access. 
[0046] It is apparent from the flowchart of figure 3 that 
an administrator may set at least two different pass- 
words for a user in the directory. The administrator may 
force the user to use different passwords depending on io 
the access mode (local or remote) and thus improve the 
security of the network. This feature may be overridden 
if the administrator sets the "PppProfile" attribute to 0. 
The user will then only use one password independently 
of the access mode, which may improve his comfort 75 
[0047] Provided that the system according to the 
invention has a front-end for each authentication proto- 
col used on the network, it allows each user to have a 
single user identifier and a reduced number of pass- 
words usable for any access or service on the network 20 
needing an authentication. The security of the network 
is improved when the administrator forces the user to 
have two passwords, one for local accesses, the other 
for remote accesses. An advantage of the system is that 
different front-ends may share the same password 25 
(PppPassWd, SlipPassWd) for the same access mode 
(PPP, SLIP). 

[0046] User entries in the directory are customized for 
the needs of the invention, i.e. they have specific 
attributes which are not necessarily defined in existing 30 
directories. Directory service protocols, such as LDAP, 
are extensible in that an administrator may define new 
entry types in the directory, which entries may inherit 
attributes from pre-existing entry types or have newly 
defined attributes. 35 
[0049] With LDAP, each entry of the directory is an 
instance of an "object class". An object class defines the 
attributes which must be used and the attributes which 
may be used in a corresponding entry. In this manner, 
new entry types may be added to the directory, trans- 40 
parently, provided that the LDAP client and the LDAP 
server both use the same object class definitions. An 
LDAP object class definition for user entries having the 
attributes exemplified above would be: 



objectclass RemoteUser 

superior top 

requires 
uid 

allows 

userPassword 

PppPassWd, 

PppProFile, 

SlipPassWd, 

SlipProfile, 



[0050] The statement "superior top" indicates that the 
object class inherits from the attributes of a previously 
defined object class "top". The statement "requires" is 
followed by a list of attributes that all the corresponding 
entries of the directory must have. The statement 
"allows" is followed by a list of attributes which are 
optional. 

[0051] An instance of this object class, i.e. a corre- 
sponding entry in the directory, could be defined as fol- 
lows: 

dn: uid = XUserld, I = ?, o = ?, c = ? 
objectclass = RemoteUser 
uid = XUserld 
userPassword = XPassWd 
PppPassword = XPassWd2 
PppProfile= 1. 

[0052] The statement "dn:" defines the "distinguished 
name" which is a unique identifier for the entry. This dis- 
tinguished name is defined so that the entries are 
organized hierarchically. For example, it defines the 
country "c", the organization "o", the location or city "I", 
and finally the user "uid". The statement "objectclass = 
RemoteUser" identifies the object class to which the 
entry belongs. 

[0053] For ease of comprehension, only a limited 
number of attributes have been described, allowing a 
minimum authentication procedure. In practice, authen- 
tication procedures use more attributes, such as pass- 
word expiration dates, check information, encryption 
keys, information for logging and debugging purposes... 
Those skilled in the art will add such attributes to the 
entries and object classes of a directory service and 
build the corresponding mapping tables in the front- 
ends for the various protocols which may be used for 
authentication. 
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Claims 

1 . A network access authentication system including: 

a directory service (24) containing a remote 5 . 
access password and a standard access pass- 
word fa each user of the network; 
an authentication protocol that provides infor- 
mation on whether a user is accessing the net- 
work locally or remotely; and 10 
a front-end (22) between the directory service 
and the authentication protocol, for receiving a 
user identifier and a user password entered by 
a user through said authentication protocol, 
retrieving from the directory service the remote is 
access password and the standard access 
password corresponding to the user identifier, 
and granting access to the network when the 
authentication protocol indicates a remote 
access and the user password equals the 20 
remote access password, or when the authen- 
tication protocol indicates a local access and 
the user password equals the standard access 
password. 

2. A network access authentication system including: 

a directory service (24) containing a remote 
access password, a standard access pass- 
word, and a remote access password enable 30 
flag for each user of the network; 
an authentication protocol that provides infor- 
mation on whether a user is accessing the net- 
work locally or remotely; and 
a front-end (22) between the directory service 35 
and the authentication protocol for receiving a 
user identifier and a user password entered by 
a user through said authentication protocol, 
retrieving from the directory service the remote 
access password, the standard access pass- 40 
word, and the remote access password enable 
flag corresponding to the user identifier, and 
granting access to the network if the authenti- 
cation protocol indicates a remote access, the 
remote access enable flag has an active state, 45 
and the user password equals the remote 
access password, else if the authentication 
protocol indicates a local access or the remote 
access enable flag has an inactive state, and 
the user password equals the standard access so 
password. 

3. The authentication system of claim 1 or 2, wherein 
the front-end is a client for a protocol used by the 
directory service and a server for the authentication 55 
protocol, and includes a protocol attribute transla- 
tion table for exchanging information between the 
authentication protocol and the directory service 



protocol. 

4. The authentication system of claim 1 or 2, wherein 
the directory service uses the Lightweight Directory 
Access Protocol (LDAP), whereby each entry in the 
directory service is an instance of a predefined 
object class defining attributes which are used by 
the entry, a specific object class being created for 
the network users, that defines the attributes nec- 
essary for authenticating the users. 

5. The authentication system of claim 1 or 2, wherein 
the front-end is an application executed on a com- 
puter hosting the directory service. 

6. The authentication system of claim 1 or 2, including 
several authentication protocols and one front-end 
for each authentication protocol. 

7. A network access authentication method using a 
directory service (24) containing a remote access 
password and a standard access password for 
each user of the network, including the steps of: 

receiving (100) a user identifier and a user 
password entered by a user through an authen- 
tication protocol that provides information on 
whether the user is accessing the network 
locally or remotely; 

retrieving (102) from the directory service the 
remote access password and the standard 
access password corresponding to the user 
identifier; 

if the authentication protocol indicates a remote 
access, comparing (116) the user password to 
the remote access password, else comparing 
(118) the user password to the standard 
access password; and 

granting access (112) to the network if the 
comparing step is successful. 

8. A network access authentication method using a 
directory service containing a remote access pass- 
word, a standard access password, and a remote 
access password enable flag for each user of the 
network, including the steps of: 

receiving (100) a user identifier and a user 
password entered by a user through an authen- 
tication protocol that provides information on 
whether the user is accessing the network 
locally or remotely; 

retrieving (102) from the directory service the 
remote access password, the standard access 
password, and the remote access password 
enable flag corresponding to the user identifier; 
if the authentication protocol indicates a remote 
access and the remote access enable flag has 
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an active state, comparing (1 16) the user pass- 
word to the remote access password, else 
comparing (118) the user password to the 
standard access password; and 
granting access (112) to the network if the s 
comparing step is successful. 

9. A network access authentication system including : 

a directory service (24) containing a remote to 
access password and a standard access pass- 
word for each user of the network; 
means (22) for receiving a user identifier and a 
user password entered by a user through an 
authentication protocol that provides informa- is 
tion on whether the user is accessing the net- 
work locally or remotely; 
means for retrieving from the directory service 
the remote access password and the standard 
access password corresponding to the user 20 
identifier; 

means for comparing the user password to the 
remote access password rf the authentication 
protocol indicates a remote access, else the 
user password to the standard access pass- 25 
word; and 

means for granting access" to the network if the 
means for comparing indicate an equality. 

10. A network access authentication system including: 30 

a directory service (24) containing a remote 
access password, a standard access pass- 
word, and a remote access password enable 
flag for each user of the network; 35 
means (22) for receiving a user identifier and a 
user password entered by a user through an 
authentication protocol that provides informa- 
tion on whether the user is accessing the net- 
work locally or remotely; 40 
means for retrieving from the directory service 
the remote access password, the standard 
access password, and the remote access 
password enable flag corresponding to the 
user identifier; 45 
means for comparing the user password to the 
remote access password if the authentication 
protocol indicates a remote access and the 
remote access enable flag has an active state, 
else the user password to the standard access so 
password; and 

means for granting access to the network if the 
means for comparing indicate an equality. 

1 1 . The authentication system of claim 9 or 1 0, wherein ss 
said means for receiving, retrieving, comparing and 
granting access are included in a front-end (22) 
which is a client for a protocol used by the directory 



service and a server for the authentication protocol, 
and which includes a protocol attribute translation 
table (22-1) for exchanging information between the 
authentication protocol and the directory service 
protocol. 
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